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Description 

[0001] The present invention relates to a method for 

delivering messages in a communication network, as 
well as to a messaging functionality device and a term!- 5 
nal device therefor. 

[0002] The 3^^ Generation Partnership Project 
(3GPP) currently discusses the issue of a multimedia 
messaging service center (MMSC) as a network ele- 
ment in a communication network, e.g. for the use in the 
general packet radio system (GPRS) and the universal 
mobile telecommunications system (UMTS). Unfortu- 
nately, most of it is still undefined, like the management 
of the capabilities and the user profile of the terminal. 
[0003] The functionality of a multimedia messaging is 
service center, from the technical viewpoint, provides a 
non-realtime service which operates partly in store-and- 
fonA^ard fashion. Additionally, multimedia messages are 
sent using the GPRS air interface, for example, and the 
contents of the messages can be text, images, speech, 20 
video clips or the like, or any arbitrary combination of 
these. For example, these contents can be delivered 
from one mobile station to another using this multimedia 
messaging service. 

[0004] According to the service description of multi- 25 
media messaging, the content and length of the mes- 
sage is in principle unlimited. However, due to the vari- 
ous different types of terminals (e.g. mobile terminals), 
a large number of different capabilities of these termi- 
nals is present in the network. Consequently, each of 
these terminals Inevitably causes its own specific re- 
strictions and limitations, in particular with respect to the 
possibility of handling a multimedia message. 
[0005] For example, the available storage capacity is 
limited and may differ between different terminals, and 
thus, not all of the terminals can be able to receive all 
possible contents. Furthermore, the capabilities of a sin- 
gle terminal may change dynamically, e.g. If the terminal 
has already received and stored a message, the remain- 
ing memory will be reduced. Similarly, the terminal can 
be connected or disconnected to or from other devices 
like laptops etc. 

[0006] Moreover, in addition to the limitations caused 
by the terminal capabilities, the users may want to cre- 
ate or modify their own user profile, thereby also result- 
ing in special restrictions. For example, a user may want 
to have certain types of multimedia messages to be 
stored in the multimedia messaging service center, for- 
warded to an internet address or discarded. These user 
defined restrictions can be based for example on the 
size of the multimedia message, the content-type or the 
sender. 

[0007] As can be seen from the foregoing, there aris- 
es the problem, that certain parts of the multimedia mes- 
sage or even the whole message may not be managed 
by the recipient terminal due to a lack of capabilities to 
receive, store, process or display the multimedia mes- 
sage. Consequently, the uncontrolled transmission of 



multimedia messages can cause serious problems up 
to system failures in the terminals which may lead to at 
least a partly breakdown of the terminal functionality, 
thus being off communication. 
[0008] Moreover, document WO 98/00787 discloses 
an e-mail system implemented on a server having a net- 
work connection which receives and forwards e-mail 
messages based on subscriber-supplied criteria. When 
a message is received addressed to the subscriber, 
characteristics of the message, such as existence of 
and size of attachments, are compared to characteris- 
tics previously supplied by the subscriber. If a match is 
found, the subscriber is notified, such as by a page to a 
pager carried by the subscriber, of the message and the 
nature of the match. Facility is provided at the server for 
the subscriber to then call the server, log on, and provide 
instructions for forwarding the matched message. For- 
warding may be to such as handheld device or a note- 
book computer operated by the subscriber, or to a mail- 
box of mailboxes on other senders, or any combination. 
A subscriber is then in control of points of delivery of 
incoming e-mail messages. 

[0009] Furthermore, document WO 99/0691 5 defines 
a message processing and fonA/arding system for 
processing electronic messages In digital format re- 
ceived over a computer communication path or network, 
and fonwarded over a telephone circuit switched net- 
work to user's receiver, such as a pager. A content proc- 
essor in a message server processes the received dig- 
ital message in accordance with knowledge of the re- 
ceiver's capabilities and user-configured message filter- 
ing information to create a customized second message 
suitable for handling by the user's receiver at a remote 
physical location. Also, the system defines a distributed 
architecture for global paging, including multiple redun- 
dancy, to yield a robust system. In a preferred embodi- 
ment, the original digital message is part of an e-mail 
message received and fonwarded through a convention- 
al computer communication network (111) such as the 
Intemet. 

[0010] Therefore, it is an object of the present inven- 
tion to provide a method for delivering messages in a 
communication network consisting of at least one termi- 
nal and a messaging functionality which is free from the 
above drawbacks. Furthermore, a messaging function- 
ality device and a terminal device adapted therefor are 
to be provided. 

[0011] According to the present invention, this object 
is achieved by what is set forth in the appended inde- 
pendent claims. 

[0012] Advantageous further developments of the 
present invention are as set out in the respective de- 
pendent claims. 

[001 3] Hence, it is an advantage of the present inven- 
tion that the handling of the messages is based on the 
capabilities of the recipient terminal and the user profile 
of the corresponding subscriber. Accordingly, it is pos- 
sible to correspondingly handle each message and 
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each part of this message. In conclusion, failures or 
functionality breakdowns of the terminal are no longer 
possible and the method according to the invention fur- 
ther provides a large scope for the subscriber for a flex- 
ible and free participation in the network. 
[0014] Preferred embodiments of the present inven- 
tion are described herein below in detail by way of ex- 
ample with reference to the accompanying drawings. In 
which: 

Fig. 1 shows a schematic diagram of the basic sig- 
naling sequence for transmitting a multimedia mes- 
sage between a multimedia messaging service 
center and a recipient terminal according to a first 
embodiment of the present invention; 

Fig. 2 shows a flow-chart illustrating an example for 
the functionality implemented at the multimedia 
messaging service center after receiving a new mo- 
bile terminated multimedia message according to a 
second embodiment of the present invention; and 

Fig. 3 shows another flow-chart illustrating an ex- 
ample for the functionality implemented at the ter- 
minal after receiving an MMSNotify message ac- 
cording to the second embodiment of the present 
invention. 

[0015] According to the present invention, a submis- 
sion of a multimedia message as an example for a mes- 
sage to be delivered in a communication network is han- 
dled according to capabilities and a user profile of a re- 
cipient terminal like for example a mobile station. The 
decision how to handle the submission is based on the 
circumstance that content(s), size and type(s) of the 
multimedia message, the capabilities of the terminal, 
and the user profile of a subscriber related to said ter- 
minal are available to respective decision means. 
[0016] A handling of those messages to be delivered 
will be done in another element of the communication 
network, i.e. a network device having a messaging func- 
tionality implemented. During the following description 
of the preferred embodiments of the invention, the de- 
scription will be made by referring to the example of a 
multimedia messaging service center as such a network 
device having implemented the messaging functionality 
and by referring to the example of a multimedia mes- 
sage as a delivered message. Nevertheless, it is to be 
noted that these examples are by no way limiting. 
Namely, also a monomedia message could be delivered 
and the message functionality need not be implemented 
in a single network device such as a multimedia mes- 
saging service center, but can also be a distributed func- 
tionality. 

[001 7] With respect to the above mentioned decision, 
for the sake of explanation, the multimedia message can 
be regarded as multimedia messaging service center 
originated while the terminal capabilities and the user 



profile can be regarded as being inherent to a respective 
terminal. Hence, information has to be transmitted in ei- 
ther way to enable a decision. 
[0018] Further, for the sake of convenience, it would 
5 be appropriate if the decision is automated and opti- 
mized depending on the parameters provided by the ter- 
minal and the user. 

[0019] Since the multimedia message can have a cer- 
tain format, multiple parts (segments), different contents 

10 (text, images, speech, videos, etc.). a different size, or 
a sender identity, it is apparent that It is dependent on 
the capabilities of the recipient terminal and the currently 
defined user profile, whether the terminal is able to re- 
ceive, display or process the multimedia message, and 

15 further, dependent on whether the subscriber wishes to 
do so. 

[0020] Consequently, the result of the decision as to 
how to handle the multimedia message can be that it 
shall be delivered completely, in part or modified, that it 

20 shall be discarded, stored in the multimedia messaging 
service center or forwarded, for example, to an internet 
email-address. Besides, the storage of the multimedia 
message in the multimedia messaging service center 
will in the most cases be limited to a certain time period, 

25 since there is presumably no unlimited memory availa- 
ble in the multimedia messaging service center (conse- 
quently, the MMSC may inform the subscriber by a re- 
spective notification about the expiry of the time period 
before erasing the stored message). If the multimedia 

30 message shall only be delivered in part, it is possible 
that also the not delivered parts are stored, forwarded 
or discarded. The case of a modification of the multime- 
dia message might usually be the conversion of the mul- 
timedia message from one format to another, but also a 

35 compression or any other kind of processing the data 
shall be understood by this expression. As a result, a 
multimedia message which is not as such divided into 
parts can be segmented by this processing. With regard 
to the several possibilities of how to handle the submis- 

40 sion of the multimedia message, the result of the deci- 
sion might finally also be a respective combination of 
the items discussed above. 

[0021] Apart from that, if the multimedia messaging 
service center is designated as a new network element 

45 for the general packet radio and universal mobile tele- 
communications systems, the data transmission will 
most likely be performed with protocol data units in non- 
realtime by use of the respective other network ele- 
ments according to said systems, which other network 

50 elements are omitted from the description of the present 
invention for the sake of distinctness. 

First Embodiment 

55 [0022] According to a first embodiment of the present 
invention, the decision concerning the selection of the 
delivery of a multimedia message is made in the multi- 
media messaging service center (MMSC). The basic 
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idea for this approach resides in the fact that, after a 
new multimedia message has been received, the multi- 
media messaging service center is immediately able to 
decide which type of delivery has to be selected. Stated 
in other words, the multimedia messaging service cent- 
er acts as a pre-filter for the terminal. 
[0023] To provide such a functionality, the terminal ca- 
pabilities and the current user profile have to be stored 
in the multimedia messaging service center. Further- 
more, this information has to be updated under certain 
conditions. If these information (terminal capabilities 
and user profile) and the imparted multimedia messag- 
ing service center are never changed at all, the Informa- 
tion has to be submitted and stored once and never to 
be updated. Of course, these prerequisites are nearly 
never met. Hence, the initial information and the up- 
dates thereof have to be submitted to the multimedia 
messaging service centers in order to keep the informa- 
tion stored therein valid. 

[0024] This information can include a display type of 
said terminal, a keyboard type of said terminal, codecs 
supported by said terminal, a memory size of said ter- 
minal, an electrical connection of said terminal to other 
devices, an external accessory attachment to said ter- 
minal or the like, and of course a current user profile. 
[0025] There are several possible conditions when to 
submit the information from the terminal to the multime- 
dia messaging service center and the possibility of up- 
dating is not limited to only one condition. However, the 
update should be coupled to the necessity to update, or 
at least to the possibility of submitting the information 
with other data (this can be any signaling sequence be- 
tween these two network elements) that has to be sub- 
mitted, in order to avoid a cluttering of traffic. Conse- 
quently, the condition when the terminal starts its sign- 
aling sequence to submit the information is predeter- 
mined. This condition can be a login of said terminal into 
said network, a change of connection conditions of said 
terminal, a context activation or the change of a context 
condition, a user profile creation or modification, a ter- 
minal originated traffic or a terminal terminated traffic, a 
request of said multimedia messaging service center, a 
notification of said multimedia messaging service center 
concerning the presence and/or the contents of a new 
multimedia message to said terminal, or the like. 
[0026] With reference to Fig. 1, the signaling se- 
quence for submitting the information about the capa- 
bilities of the terminal and the current user profile is il- 
lustrated by the example of submitting the information 
upon the predetermined condition of context activation. 
[0027] Consequently, in a first step S1 1 . a terminal MS 
such as a mobile station requests a context activation 
to the multimedia messaging service center MMSC via 
a support node SN. With this request for context activa- 
tion, the terminal MS submits simultaneously its capa- 
bilities CAP and current user profile UP. According to 
examples of the current network being the GPRS or 
UMTS, the whole signaling shown in Fig. 1 can take 



place by using protocol data units PDU. 
[0028] After this transmission has been completed, 
the multimedia messaging service center MMSC stores 
the user profile UP of the terminal MS. Due to the capa- 

5 bilities of the multimedia messaging service center, it 
may be possible or necessary to adapt the user profile 
UP of the terminal MS within the range of the capabilities 
CAP of the terminal MS. However, the user may inhibit 
such amendments of his prefenred user profile. The stor- 

10 age of the user profile UP and its eventual processing 
is done in a step S12. 

[0029] In a third step S13 at least the acknowledge- 
ment of the context activation is submitted from the mul- 
timedia messaging service center MMSC to the terminal 

15 MS via the support node SN. 

[0030] However, if a multimedia message MM for the 
terminal MS is currently present in the multimedia mes- 
saging service center MMSC, there will be a step S14 
before step S13, wherein this multimedia message MM 

20 is handled according to the user profile UP stored in the 
multimedia messaging service center MMSC. The han- 
dling of the multimedia message MM corresponds to the 
result of a decision process which is based on the ca- 
pabilities CAP and the user profile UP of the terminal 

25 MS which are now stored in the multimedia messaging 
service center MMSC. The possible results of this deci- 
sion process are discussed above in detail and it is men- 
tioned again that according to the first embodiment, this 
decision is made by the multimedia messaging service 

30 center MMSC. 

[0031] According to the result of this decision, the 
handling of the multimedia message MM may require a 
processing of the data of the multimedia message MM 
(e.g. in the cases of a modified or a partly deliverance) 

35 or not, as is mentioned above. In any case, if at least 
parts of the multimedia message MM have to be sub- 
mitted to the terminal MS, this is done in the step S13 
together with the submission of the context activation 
acknowledgement. 

40 [0032] As mentioned before, the example depicted in 
Fig. 1 is given by way of illustration only, while the first 
embodiment is not limited thereto. Consequently, a re- 
spective adaptation of the process shown In Fig. 1 to the 
other possibilities according to the first embodiment as 

45 described above is fully apparent to those skilled in the 
art. 

Second Embodiment 

50 [0033] Apart from the solution according to the first 
embodiment, there is the alternative to maintain the ter- 
minal capabilities and user profile information only at the 
terminal side and consequently, to take the decision 
concerning the selection of the delivery of a multimedia 

55 message by the terminal. 

[0034] Therefore, the basic idea of the second em- 
bodiment resides in that the terminal capabilities and us- 
er profile infomriation is stored in the terminal, e.g. in the 
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terminal equipment or, in the case of a mobile terminal, 
in the SIM or In both. Due to this, the decision regarding 
the delivery of a multimedia message is taken in the ter- 
minal. 

[0035] The functionality of the multimedia messaging 
service center and of the terminal according to the sec- 
ond embodiment are now described with reference to 
Fig. 2 and Fig. 3. 

[0036] Fig. 2 illustrates an example of the functionality 
of the multimedia messaging service center MMSC ac- 
cording to this embodiment upon receipt of a new mobile 
terminated multimedia message MM. As can be gath- 
ered therefrom, the multimedia messaging service cent- 
er MMSC automatically sends a special control mes- 
sage MMSNotify in a step S21 to the terminal MS after 
it has received a new multimedia message MM (step 
S20). The MMSNotify message contains information 
about the actual multimedia message MM such as the 
total size of the message, the content(s), the content 
type(s), a human readable description and so on. 
[0037] On the basis of the stored information about 
the terminal capabilities CAP and its current user profile 
UP, the terminal MS now processes the information In- 
cluded in the MMSNotify message and accordingly de- 
cides how to handle the multimedia message MM. 
Based on this decision process, the terminal MS sends 
a corresponding reply message to the multimedia mes- 
saging center MMSC, which is received by the multime- 
dia messaging service center MMSC in a step S22. This 
process is illustrated by way of example in Fig. 3, which 
will be described herein below. 
[0038] It is noted that the present invention does not 
restrict the means by which the MMSNotify message is 
delivered to the terminal MS. For example, the multime- 
dia messaging service center MMSC could send the 
MMSNotify message as a special SMS message, which 
is then parsed by the terminal MS, or the multimedia 
messaging service center MMSC could use a specific 
bearer (e.g. a control channel) dedicated to multimedia 
messaging service. 

[0039] Anyway, the signaling sequence according to 
the second embodiment for the exchange of messages 
and information, respectively. Is based upon the follow- 
ing principle. Upon receipt of the MMSNotify message, 
the terminal MS submits the MMSResultRequest mes- 
sage as a reply, which is received by the multimedia 
messaging service center MMSC in the step S22. The 
possible MMSResultRequest messages do, however, 
differ from each other due to the result of the decision 
process. Hence, the MMSResultRequest can be a 
MMSDeliverReq, a MMSStoreReq, a MMSForwardReq 
or a MMSDiscardReq, for example. 
[0040] Hence, In a step S23. the multimedia messag- 
ing service center MMSC checks If the reply of the ter- 
minal MS is the MMSStoreReq message, and in case 
of "yes", the multimedia message MM is stored in the 
multimedia messaging service center in a step S26. In 
case of "no" the process proceeds further to the step 



S24 to check whether the reply is the MMSDeliverReq 
message. 

[0041] If the MMSDeliverReq message was replied by 
the terminal MS, the process flows to a step S27, where- 

5 in the multimedia messaging service center MMSC 
checks the MMSDeliverReq message, whether the mul- 
timedia message shall be delivered partly or completely. 
The step S29 shown in Fig. 2 represents the case of a 
partly deliverance of the multimedia message MM to the 

10 terminal MS. followed by the above mentioned step S26, 
wherein at least the undelivered parts of the multimedia 
message MM are stored in the multimedia messaging 
service center MMSC. In contrast thereto does the step 
S210 represent the case of a completely deliverance of 

15 the multimedia message MM to the multimedia messag- 
ing service center MMSC, followed by a step S211, 
wherein the multimedia message MM is removed from 
the multimedia messaging service center MMSC after 
the deliverance. 

20 [0042] -If the MMSDeliverReq message was not re- 
plied by the terminal MS, there is checked in a step S25 
of the process, whether the MMSFonwardReq message 
was replied, and if not, it is assumed that the MMSDis- 
cardReq message is present and the multimedia mes- 

25 sage MM is removed from the multimedia messaging 
service center MMSC according to the step S211. In 
case the MMSFonwardReq message is present, the 
multimedia message MM is first fonA/arded in a step S28 
to a destination given by the MMSFonwardReq mes- 

30 sage, before it is removed from the multimedia messag- 
ing service center MMSC in the step S211. 
[0043] Now the functionality of the terminal MS after 
receiving an MMSNotify message in a step S30 accord- 
ing to the step S21 of Fig. 2 Is described with reference 

35 to Fig. 3. 

[0044] Specifically, the terminal MS checks its capa- 
bilities CAP and user profile UP in a step S31 , followed 
by the corresponding decision steps S32-S35. As can 
be seen from Fig. 3, the choice to leave the decision to 

40 the user, which is not part of the present invention, is 
included as an option corresponding to the step S32. In 
case the user profile UP is set such that the user shall 
decide on the delivery of a multimedia message MM. 
the result of his input is carried further to the steps 

45 S33-S35. When the decision is done automatically, ac- 
cording to the second embodiment of the present inven- 
tion, the terminal MS decides due to its user profile UP 
and capabilities CAP how to handle the multimedia mes- 
sage MM present in the multimedia messaging service 

50 center MMSC. Anyway, also in this case the result is 
carried further to the steps S33-S35. 
[0045] The several choices for the terminal MS how 
to decide on the delivery of the multimedia message MM 
are discussed above, and some of these are shown in 

55 Fig. 3 as explanatory examples. That is, in step S33 the 
terminal checks whether the result is to retrieve the mul- 
timedia message MM partly or completely, and if this is 
the case, a step S37 follows, wherein the MMSDeiiver- 
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Req message is sent to the multimedia messaging serv- 
ice center MMSC. If the multimedia message MM shall 
not be retrieved, but the result is checked in a step S34 
that it is to be forwarded, there follows a step S38 to 
send the MMSFonwardReq message to the multimedia 
messaging service center MMSC. In case the result is 
not to forward the message, the process flows to step 
S35 to check whether the result is to have the multime- 
dia message MM to be stored in the multimedia mes- 
saging service center MMSC. If this is true, the step S39 
follows which includes the sending of the MMSStoreReq 
message to the multimedia messaging service center 
MMSC, if It is not true, the step S40 follows which in- 
cludes the sending of the MMSDiscardReq message to 
the multimedia messaging service center MMSC, as- 
suming that this is the result of the decision process. 
[0046] All of the steps S37-S40 are followed in any 
case by a step S41 . in which the user profile is one more 
time checked, whether the user is to be notified by a 
proper notification in a step S42 about the presence of 
a multimedia message MM and, moreover, probably 
about the performed handling of it, or not. In both cases, 
the flow is ended until another MMSNotify message will 
be received. 

[0047] It is mentioned, that the reply message sent by 
the terminal MS according to one of the steps S37-S40 
of Fig. 3 is received by the multimedia messaging serv- 
ice center MMSC in the step S22 of Fig. 2. Further, this 
reply message contains in any way every information 
needed for the multimedia messaging service center 
MMSC to act according to the terminal originated deci- 
sion on the delivery of the multimedia message MM. 
[0048] It is noted again, that the examples depicted 
by Figs. 2 and 3 are not limiting the invention, and the 
range of choices for the delivery of the multimedia mes- 
sage has been set out above in greater detail. According 
to the present invention, a further refinement and/or 
modification of the flow-charts of Figs. 2 and 3 can easily 
be obtained along the lines of the description as set out 
above. 

[0049] As a further alternative within the second em- 
bodiment, the signaling between the terminal and the 
multimedia messaging service center could be imple- 
mented with a single request-reply message pair. Stated 
in other words, the terminal could always reply to the 
MMSNotify message with a MMSNotifyReply message. 
In this case, the desired functionality of the terminal and 
the multimedia messaging service center can be 
achieved by allocating a control flag (e.g. in 2-bit repre- 
sentation) to each part of the multimedia message in 
said MMSNotifyReply message. If the value of the flag 
is either deliver, store, fonward or discard, the terminal 
is able to inform the multimedia message service center 
with a single reply message how to handle each part of 
the multimedia message. 

[0050] This kind of solution would allow a more flexi- 
ble functionality. For example, it is fully apparent that, 
according to this altemative. it would be possible to in- 



struct the multimedia messaging service center with one 
reply message to treat each part of the multimedia mes- 
sage independent and separated from the other parts, 
so that some parts can be delivered to the terminal, 
5 some parts can be forwarded to an internet email ad- 
dress etc. 

[0051] However, this provides that the multimedia 
message is clearly defined In parts and that the multi- 
media messaging service center is able to handle each 

^0 part separated. 

[0052] According to the second embodiment, there 
arise the following further advantages: 
[0053] The terminal capabilities and user profile Infor- 
mation do not have to be maintained in the multimedia 

15 messaging service center, whereby both the storage 
and processing capacities of the multimedia messaging 
service center are not consumed, rather being left for 
other objects. 

[0054] Furthermore, the information does not have to 

20 be delivered each time upon predetermined conditions 
to keep the information stored in the multimedia mes- 
saging service center valid. Therefore, no extra signal- 
ing is caused between the terminal and the multimedia 
messaging service center. In conclusion, it is guaran- 

25 teed that the Information is always up to date and no 
traffic cluttering appears due to update signaling. 
[0055] Still further, no extra amount of processing has 
to be done in the multimedia messaging service center. 
Since It can be expected that the structure of the multi- 

30 media messaging sen/ice center can be left on a less 
complex level according to the second embodiment, i. 
e. the implementation of the multimedia messaging 
service center becomes simpler and its performance re- 
quirements decrease, there might be reasons why this 

35 embodiment could be preferable. 

[0056] As is described above, the present invention 
proposes a method for delivering messages in a com- 
munication network consisting of at least one terminal 
and a messaging functionality, said method comprising 

40 the steps of receiving a message MM for said terminal 
MS by said messaging functionality MMSC; sending a 
notification MMSNotify about the presence of said mes- 
sage MM from said messaging functionality MMSC to 
said terminal MS; deciding by said terminal MS due to 

45 its capabilities CAP and current user profile UP how to 
handle said received message MM; replying by said ter- 
minal MS to the notification sent by said messaging 
functionality MMSC. therewith instructing according to 
the result of said decision step; and handling said mes- 

50 sage MM by said messaging functionality MMSC ac- 
cording to said instructions. 

[0057] It should be understood that the above descrip- 
tion and accompanying figures are only intended to il- 
lustrate the present invention by way of example only. 
55 The preferred embodiments of the present invention 
may thus vary within the scope of the attached claims. 



11 



EP1 169 827 B1 



12 



Claims 

1 . A method for delivering messages in a communica- 
tion network comprising at least one terminal (MS) 
and a messaging functionality (MMSC), said meth- 
od comprising the steps of 

receiving a message (MM) for said terminal 
(MS) by said messaging functionality (MMSC); 

deciding by said messaging functionality 
(MMSC), based on a content, size and type of said 
message as well as on information concerning ca- 
pabilities (CAP) of said terminal and the user profile 
(UP) of a subscriber related to said terminal (MS), 
all of which are at the same time available to said 
messaging functionality, how to handle a message 
(MM) for said terminal (MS) received by said mes- 
saging functionality (MMSC); and 

handling said message (MM) by said messag- 
ing functionality (MMSC) according to the result of 
said decision step, 
characterized in that 

said information concerning the capabilities 
(CAP) of the terminal (MS) and a current user profile 
(UP) thereof are submitted by said terminal (MS) to 
said messaging functionality (MMSC) upon the oc- 
currence of a predetermined condition which is at 
least one of the following events a login of said ter- 
minal (MS) into said network, a change of connec- 
tion conditions of said terminal (MS), a context ac- 
tivation or the change of a context condition, a user 
profile (UP) creation or a user profile (UP) modifica- 
tion, a terminal originated traffic or a terminal termi- 
nated traffic, a request of said messaging function- 
ality (MMSC), a notification of said messaging func- 
tionality (MMSC) concerning the presence of a new 
message (MM) to said terminal (MS), and a notifi- 
cation of said messaging functionality (MMSC) con- 
cerning the content, type and size of a new mes- 
sage (MM) to said terminal (MS). 

2. A method according to claim 1 , further comprising 
the step of storing said information in said messag- 
ing functionality (MMSC). 

3. A method according to claim 1 , wherein 

the result of said decision step can at least reside 
in that said message (MM) for said terminal (MS) is 
delivered completely, partly or modified to said ter- 
minal (MS), that said message (MM) is discarded, 
that said message (MM) Is fonvarded to another ter- 
minal, or that said message (MM) is stored in said 
messaging functionality (MMSC). 

4. A method according to claim 1 , wherein said infor- 
mation concerning said capabilities (CAP) of said 
terminal (MS) comprises at least one of the follow- 
ing: a display type of said terminal (MS), a keyboard 
type of said terminal (MS), codecs supported by 



said terminal (MS), a memory size of said terminal 
(MS), an electrical connection of said terminal (MS) 
to other devices, or external accessory attachment 
to said temninal (MS). 

5 

5. A method for delivering messages in a communica- 
tion network comprising at least one terminal (MS) 
and a messaging functionality (MMSC), said meth- 
od comprising the steps of 

10 receiving a message (MM) for said terminal 

(MS) by said messaging functionality (MMSC); and 
sending a notification (MMSNotify) about the 
presence of said message (MM) from said messag- 
ing functionality (MMSC) to said terminal (MS). 

15 wherein said notification at least indicates a con- 
tent, size and type of said message; 
characterized by further comprising the steps of 

deciding by said terminal (MS), based on a 
content, size and type of said message as well as 

20 on capabilities (CAP) of said terminal (MS) and the 
user profile (UP) of a subscriber related to said ter- 
minal (MS), all of which are at the same time avail- 
able to said terminal, how to handle said received 
message (MM); 

25 replying automatically by said terminal (MS) 

to the notification sent by said messaging function- 
ality (MMSC), therewith instructing according to the 
result of said decision step; and 

handling said message (MM) by said messag- 

30 ing functionality (MMSC) according to said instruc- 
tions. 

6. A method according to claim 5. wherein the result 
of said decision step can at least reside in that said 

35 message (MM) for said terminal (MS) is delivered 
completely, partly or modified to said terminal (MS), 
that said message (MM) is discarded, that said 
message (MM) is fon^^arded to another terminal, or 
that said message (MM) is stored in said messaging 

40 functionality (MMSC). 

7. A method according to claim 5, wherein said notifi- 
cation (MMSNotify) about the presence of said 
message (MM) from said messaging functionality 

45 (MMSC) to said terminal (MS) further notifies about 
at least contents, types and size of said message 
(MM). 

8. A method according to claim 7. wherein said termi- 
50 nal (MS) replies to said messaging functionality 

(MMSC) in the course of the signaling by sending a 
notification reply message which contains a control 
flag for each part of said message (MM), and the 
value of said control flag could be either deliver. 
55 modify, store, fonward or discard. 

9. A messaging functionality device comprising 

receiving means adapted to receive messag- 
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es (MM) and information; 

processing means adapted to process re- 
ceived infonmation data and messages (MM); 

storing means; 

sending means adapted to send information 
and messages (MM), respectively, to a terminal 
(MS). 

characterized In that 

said messaging functionality device is adapt- 
ed to perform any one of the methods according to 
claims 1 to 4. 

10. A terminal device comprising 

receiving means adapted to receive messag- 
es (MM) and information; 

processing means adapted to process re- 
ceived information data and messages (MM); 

storing means; 

sending means adapted to send information 
and messages (MM), respectively, to a messaging 
functionality (MMSC) 
characterized in that 

said terminal is adapted to perform any one 
of the methods according to claims 5 to 8. 



Patentanspriiche 

1 . Verfahren zum Ausliefern von Nachrichten in einem 
Kommunikationsnetzwerk mit zumindest einem 
Endgerat (MS) und einer Nachrichtenfunktionalit^t 
(MMSC), das Verfahren umfasst dabei die Schritte 
Empfangen einer Nachrlcht (MM) fOr das 
Endgerat (MS) durch die Nachrichtenfunktlonalitdt 
(MMSC); 

Entscheiden durch die Nachrichtenfunktiona- 
litat (MMSC) auf der Grundlage von Inhalt, Grofte 
und Art der Nachricht sowie auf der Grundlage von 
Informationen bezQglich der LeistungsfShlgkelt 
(CAP) des Endgerates und des Benutzerprofils 
(UP) eines Teilnehmers bezuglich des Endgerates 
(MS), was alles gleichzeitig der Nachrlchtenfunktio- 
nalitat verftigbar ist, wie eine durch die Nachrlch- 
tenfunktionalitat (MMSC) empfangene Nachrlcht 
(MM) fur das Endgerdt (MS) zu handhaben ist; und 

Handhaben der Nachricht (MM) durch die 
Nachrichtenfunktionalitat (MMSC) gemaii dem Er- 
gebnis des Entscheidungsschrltts, 
dadurch gekennzeichnet, dass 

die Informationen bezOglich der Lelstungsfa- 
higkeit (CAP) des Endgerates (MS) und dessen mo- 
mentanes Benutzerprofil (UP) durch das Endgerat 
(MS) an die Nachrichtenfunktionalitat (MMSC) beim 
Auftreten einer vorbestlmmten Bedingung Qbermlt- 
telt werden, die zumindest eine der nachstehend 
aufgefuhrten Ereignisse ist: ein Einbuchen des 
Endgerates (MS) in das Netzwerk, ein Wechsel von 
Verblndungszustanden des Endgerates (MS), eine 



Kontextaktivierung oder der Wechsel eines Kon- 
textzustandes, eine Benutzerprofilerzeugung (UP) 
Oder eine Benutzerprofilabwandlung (UP), ein von 
dem Endgerat veranlasster Verkehr oder ein an das 

5 Endgerat gerichteter Verkehr, eine Anfrage der 
Nachrichtenfunktionalitat (MMSC), eine Benach- 
richtigung der Nachrichtenfunktionalitat (MMSC) 
bezOglich der Gegenwart einer neuen Nachricht 
(MM) an das Endgerat (MS), und eine Benachrich- 

10 tigung der Nachrichtenfunktionalitat (MMSC) be- 
zuglich des Inhaltes. der Art und der GrCfie einer 
neuen Nachricht (MM) an das Endgerat (MS). 

2. Verfahren nach Anspruch 1 . ferner mit dem Schritt 
15 des Spelcherns der Informationen In der Nachrich- 
tenfunktionalitat (MMSC). 

3. Verfahren nach Anspruch 1, wobei das Ergebnis 
des Entscheidungsschrlttes zumindest darin beste- 

20 hen kann, dass die Nachricht (MM) fiir das Endge- 
rat (MS) vollstandig, teilweise oder abgewandelt an 
das Endgerat (MS) ausgetiefert wird. dass die 
Nachricht (MM) venA/orfen wird, dass die Nachricht 
(MM) an ein anderes Endgerat weitergeleltet wird, 

25 Oder dass die Nachricht (MM) in der Nachrichten- 
funktionalitat (MMSC) gespeichert wird. 

4. Verfahren nach Anspruch 1 , wobei die Infomiatlo- 
nen bezQglich der Leistungsfahigkeit (CAP) des 

30 Endgerates (MS) zumindest eine Anzeigeart des 
Endgerates (MS), eine Tastaturart des Endgerates 
(MS), durch das Endgerat (MS) unterstutzte Co- 
dier-Decodier-Elnrichtungen. eine SpeichergrOBe 
des Endgerates (MS), eine elektrische Verbindung 

35 des Endgerates (MS) mit anderen Vorrichtungen, 
Oder auBere ZubehOrgerate an dem Endgerat (MS) 
umfasst. 

5. Verfahren zum Ausliefern von Nachrichten in einem 
40 Kommunikationsnetzwerk mit zumindest einem 

Endgerat (MS) und einer Nachrichtenfunktionalitat 
(MMSC), das Verfahren umfasst dabei die Schritte 
Empfangen einer Nachricht (MM) fur das 
Endgerat (MS) durch die Nachrichtenfunktionalitat 

45 (MMSC): und 

Senden einer Benachrichtigung (MMSNotify) 
Dber die Gegenwart der Nachricht (MM) von der 
Nachrichtenfunktionalitat (MMSC) an das Endgerat 
(MS), wobei die Benachrichtigung zumindest inhait, 

50 GrOBe und Art der Nachricht bezeichnet; 

gekennzelchnet durch die weiteren Schritte 

Entscheiden durch das Endgerat (MS) auf 
der Grundlage von Inhalt, GrGlie und Art der Nach- 
richt sowie auf Grundlage der Leistungsfahigkeit 

55 (CAP) des Endgerates (MS) und dem Benutzerpro- 
fil (UP) eines Teilnehmers bezQglich des Endgera- 
tes (MS), was alles gleichzeitig dem Endgerat ver- 
fugbar ist, wie die empfangene Nachricht (MM) zu 



8 



15 



EP 1 169 827 B1 



16 



handhaben ist; 

automatisches Antworten durch das Endge- 
rdt(MS)aufdiedurch die Nachrichtenfunktionalttdt 
(MMSC) gesandte Benachrichtigung, womit gemSli 
dem Ergebnis des Entscheidungsschritts angewie- 5 
sen wind; und 

Handhaben der Nachhcht (MM) durch die 
Nachrichtenfunktionalitdt (MMSC) gemdfi den An- 
weisungen. 

6. Verfahren nach Anspruch 5, wobei das Ergebnis 
des Entscheidungsschrittes zumindest darin beste- 
hen kann. dass die Nachricht (MM) fOr das Endge- 
rat (MS) vollstandig. teilweise oder abgewandelt an 
das Endgerat (MS) ausgelieferl wird, dass die 
Nachricht (MM) verworfen wird, dass die Nachricht 
(MM) an ein weiteres Endgerat weitergeieitet wird, 
Oder dass die Nachricht (MM) in der Nachrichten- 
funktionalitat (MMSC) gespeichert wird. 

7. Verfahren nach Anspruch 5, wobei die Benachrich- 
tigung (MMSNotify) uber die Gegenwart der Nach- 
richt (MM) von der NachrichtenfunktionaiitSt (MM- 
SC) an das Endgerat (MS) ferner zumindest uber 
Inhalte, Arten und Grdlie der Nachricht (MM) be- 
nachrichtigt. 

8. Verfahren nach Anspruch 7, wobei das Endgerat 
(MS) der Nachhchtenfunktionalitat (MMSC) im Ver- 
lauf derSignalisierung durch Senden einer Benach- 
richtigungsantwortnachricht antwortet, die ein 
Steuerungskennzeichen fur jeden Teil der Nach- 
richt (MM) enthatt, wobei der Wert des Steuerungs- 
kennzeichens entweder Ausllefern, Abwandeln. 
Speichern, Weiterleiten oder Verwerfen sein kann. 

9. Nachrichtenfunktionalitatsvorrichtung mit 

einer Empfangseinrlchtung, die fur den Emp- 
fang von Nachrichten (MM) und Informationen an- 
gepasst ist; 

einer Verarbeitungseinrichtung, diezurVerar- 
beitung von empfangenen Informationsdaten und 
Nachrichten (MM) angepasst ist; 

einer Speichereinrichtung; 

einer Sendeeinrichtung, die zum Senden von 
Informationen bzw. Nachrichten (MM) an ein End- 
gerat (MS) angepasst ist, 
dadurch gekennzeichnet, dass 

die Nachrichtenfunktionalitatsvorrichtung zur 
DurchfQhrung eines der Verfahren gemail den Pa- 
tentansprQchen 1 bis 4 angepasst ist. 

10. Endgeratevorrichtung mit 

einer Empfangseinrichtung, die fur den Emp- 
fang von Nachrichten (MM) und Informationen an- 
gepasst ist; 

einer Verarbeitungseinrichtung, die zur Verar- 
beitung von empfangenen Informationsdaten und 



Nachrichten (MM) angepasst ist; 

einer Speichereinrichtung; 

einer Sendeeinrichtung, die zum Senden von 
Informationen bzw. Nachrichten (MM) an eine 
Nachrichtenfunktionalitat (MMSC) angepasst ist, 
dadurch gekennzeichnet, dass 

das Endgerat zum Durchfuhren eines der Ver- 
fahren gemail der PatentansprOche 5 bis 8 ange- 
passt Ist. 
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Revendicatlons 

1. Proc6d6 pour d^llvrer des messages dans un r6- 
15 seau de communication comprenant au moins un 
terminal (MS) et une fonctionnalit6 de messagerie 
(MMSC), ledit proc^d^ comprenant les stapes con- 
sistent d : 

20 recevoir un message (MM) pour (edit tenninal 

(MS) par ladite fonctlonnalit^ de messagerie 
(MMSC) ; 

decider par ladite fonctionnalit6 de messagerie 
(MMSC), sur la base d'un contenu, d'une taille 
25 et d'un type dudit message ainsi que d'informa- 

tions concernant des capacit6s (CAP) dudit ter- 
minal et le profil d'utilisateur (UP) d'un abonn6 
associ6 audit terminal (MS), I'ensemble de 
ceux-cl 6tantsimultan6ment d la disposition de 
30 ladite fonctionnalit6 de messagerie, comment 

traiter un message (MM) pour ledit terminal 
(MS) regu par ladite fonctionnalit6 de messa- 
gerie (MMSC) ; et 

traiter ledit message (MM) par ladite fonction- 
35 nalit^ de messagerie (MMSC) conform§ment 

au r^suttat de ladite 6tape de decision, 

caracterlse en ce que 
lesdites informations concernant les capaci- 
40 t6s (CAP) du terminal (MS) et un profil d'utilisateur 
actuel (UP) de celui-ci sont soumises par ledit ter- 
minal (MS) d ladite fonctionnalit^ de messagerie 
(MMSC) lors de I'apparition d'une condition pr6d6- 
termin^e qui est au moins I'un des 6v6nements 
45 suivants : une ouverture de session dudit terminal 
(MS) dans ledit r6seau, un changement de condi- 
tions de connexion dudit terminal (MS), une activa- 
tion de contexte ou le changement d'une condition 
de contexte. une creation de profit d'utilisateur (UP) 
50 ou une modification de profil d'utilisateur (UP), un 
trafic provenant d'un terminal ou un trafic aboutis- 
sant ^ un terminal, une demande de ladite fonction- 
nalit6 de messagerie (MMSC), une notification de 
ladite fonctionnalit§ de messagerie (MMSC) con- 
55 cemant la presence d'un nouveau message (MM) 
audit terminal (MS), et une notification de ladite 
fonctionnalit6 de messagerie (MMSC) concernant 
le contenu. le type et la taille d'un nouveau message 
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(MM) audit terminal (MS). 

Proc6d6 selon la revendication 1, comprenant en 
outre r6tape consistant ^ mdmoriser lesdites infor- 
mations dans ladite fonctionnalit6 de messagerie 5 
(MMSC). 

Proc6d6 seion la revendication 1 . dans lequel le r6- 
sultat de ladite 6tape de decision peut r^sider au 
moins dans le fait que ledit message (MM) pour ledit io 
terminal (MS) est d6livr6 compldtement, partielle- 
ment ou modifi6 audit terminal (MS), que ledit mes- 
sage (MM) est rejet6, que ledit message (MM) est 
achemin6 vers un autre terminal, ou que ledit mes- 
sage (MM) est m^moris^ dans ladite fonctionnalit^ is 
de messagerie (MMSC). 

Proc6d6 selon la revendication 1 , dans lequel les- 
dites informations concemant lesdites capacit6s 
(CAP) dudit terminal (MS) comprennent au moins 20 
Tune des suivantes : un type d'^cran dudit terminal 
(MS), un type de clavier dudit terminal (MS), des 
codecs support^s par ledit terminal (MS), une taiile 
de m6moire dudit terminal (MS), une connexion 
^lectrique dudit terminal (MS) d d'autres dispositifs, 25 
ou la fixation d'un accessoire externe audit terminal 
(MS). 

Proc6d6 pour d6livrer des messages dans un r6- 
seau de communication comprenant au moins un 30 
terminal (MS) et une fonctionnalit6 de messagerie 
(MMSC), ledit proc6d6 comprenant les 6tapes con- 
sistant d : 

recevoir un message (MM) pour ledit terminal 35 
(MS) par ladite fonctlonnatit^ de messagerie 
(MMSC) ; et 

envoyer une notification (MMSNotIfy) concer- 
nant la presence dudit message (MM) de ladite 
fonctionnalit6 de messagerie (MMSC) audit ter- ^0 
minal (MS), dans lequel ladite notification indi- 
que au moins un contenu, une taille et un type 
dudit message ; 

caracterise en ce qu*it comprend en outre les 
6tapes consistant § : 

decider par ledit temnlnal (MS), sur la base d'un 
contenu, d'une taille et d'un type dudit message 
ainsi que de capacit6s (CAP) dudit terminal so 
(MS) et du profil d'utilisateur (UP) d'un abonn6 
associ6 audit terminal (MS), I'ensemble de 
ceux-cl 6tant simultan6mentd la disposition du- 
dit terminal, comment tralter ledit message 
(MM) re?u ; 55 
r6pondre automatiquement par ledit terminal 
(MS) d la notification envoy6e par ladite fonc- 
tionnalit6 de messagerie (MMSC), en donnant 



avec la r6ponse des instructions conform6ment 
au r6sultat de ladite 6tape de d6cision ; et 
tralter ledit message (MM) par ladite fonction- 
nalit6 de messagerie (MMSC) confomnfement 
auxdites instructions. 

6. Proc^dS selon la revendication 5, dans lequel le r6- 
sultat de ladite 6tape de decision peut r6sider au 
moins dans le fait que ledit message (MM) pour ledit 
terminal (MS) est d6livr6 compl6tement, partielle- 
ment ou modifi6 audit terminal (MS), que ledit mes- 
sage (MM) est rejet6, que ledit message (MM) est 
achemind vers un autre terminal, ou que ledit mes- 
sage (MM) est m6moris6 dans ladite fonctionnalit§ 
de messagerie (MMSC). 

7. Proc6d6 selon la revendication 5, dans lequel ladite 
notification (MMSNotify) concernant la pr6sence 
dudit message (MM) de ladite fonctionnalitd de 
messagerie (MMSC) audit terminal (MS) informe en 
outre au moins d'un contenu, d'un type et d'une 
taille dudit message (MM). 

8. Proc6d6 selon la revendication 7, dans lequel ledit 
terminal (MS) r^pond ^ ladite fonctionnalit6de mes- 
sagerie (MMSC) au cours de la signalisation en en- 
voyant un message de r6ponse d la notification qui 
contient un indicateur de contrdle pour cheque par- 
tie dudit message (MM), et la valeur dudit indicateur 
de contrdle pourrait etre soit d6livrer. modifier, m6- 
moriser, acheminer ou rejeter. 

9. Dispositif de fonctionnalit6 de messagerie 
comprenant : 

des moyens de reception adapt6s pour rece- 
voir des messages (MM) et des informations ; 
des moyens de traitement adapt^s pour traiter 
des donn^es d'informations et des messages 
(MM) regus ; 

des moyens de memorisation ; 
des moyens d'envoi adapt6s pour envoyer des 
informations et des messages (MM), respecti- 
vement, d un terminal (MS), 

caracterise en ce que 

ledit dispositif de fonctionnalit6 de message- 
rie est adapts pour effectuer Tun quelconque des 
proc6d6s selon les revendications 1^4. 

10. Dispositif de terminal comprenant : 

des moyens de reception adapt6s pour rece- 
voir des messages (MM) et des informations ; 
des moyens de traitement adapt6s pour traiter 
des donndes d'informations et des messages 
(MM) regus ; 

des moyens de memorisation ; 
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des moyens d'envoi adapt6s pour envoyer des 
informations et des messages (MM), respecti- 
vement, d une fonctionnalit6 de messagerie 
(MMSC), 

caracterise en ce que 

ledit terminal est adapts pour efTectuer I'un 
quelconque des proc6d6s selon les revendications 
5d8. 
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